This invention relates to test and measurement systems and, more particularly, to a system for determining an acquisition sample obtained by an instrument which corresponds to a software source code statement.
In earlier days, engineers typically wrote control code for test and measurement systems in assembly language, a low-level language. Today, however, to improve development time and to enable greater functionality and complexity to be developed in shorter time, engineers typically employ high-level languages, for example C, C++, etc., to develop products. The high-level language is converted into machine code for operation on the particular processor, by a compiler/assembly/linker system, which generates assembly language and/or machine code based on the high-level source code. When debugging, the engineer must work with the low-level machine code, which typically is converted to assembly language by the debugger to aid in the understanding thereof. However since the engineer did not write the software in assembly language and since the engineer may be unfamiliar with the methods employed by the compiler to generate assembly language code corresponding to various source code statements, it becomes complicated for the engineer to understand the exact operation of the system during debug.
In accordance with the prior art, it is necessary that a user select an acquisition sample and then attempt to locate a corresponding source code statement. Also, such prior systems allow searching for an acquisition sample which corresponds to the next or previous source code statement in execution order. However, there are no systems in the prior art which enable selection of a source code statement at random from any of the source code files used to generate the executable code and which then locate a matching sample in an acquisition buffer/disassembly file.
Current test instruments, for example logic analyzers, are sophisticated devices which include extensive software support systems for governing the operation of the instruments. Some of these support systems include debugging systems, which enable an engineer using a test instrument to perform real-time characterization and debugging of an embedded system where acquired data includes (in the case of a microprocessor system) bus transactions and the like that occur during the operation of the system.
In accordance with the prior art, debugging systems were employed where the engineer debugging a system would have to trace through acquisition samples, line by line. For example, if the engineer was interested in a particular data sample that had been acquired by the system, and the corresponding source code was displayed in a debug window on a workstation, the engineer might not know what source code statement corresponded to the particular data sample, as the data samples could typically have resulted from any one of many different modules, depending on the operational characteristics and flow of the controlling software. Accordingly, if the engineer is viewing a particular source code line with the debugger, the engineer would have to make some sort of educated guess as to where a corresponding data sample might have been acquired in the acquisition buffer, and trace through a number of samples, hoping that the guess was correct and that the conditions of the source statements were appropriately met such that the desired sample did in fact appear in the acquisition buffer. This might involve stepping through multiple samples in the acquisition buffer, which was annoying for the engineer as often the particular acquisition sample could not be reached in the debugger without stepping through a great many acquisition samples, with no guarantee that the sought after sample was present in the acquisition buffer at all.